Although the Internet has had great successes in facilitating communications between computer systems and enabling electronic commerce, the computer systems connected to the Internet have been under almost constant attack by hackers seeking to disrupt their operation. Many of the attacks seek to exploit vulnerabilities of the application programs or other computer programs executing on those computer systems. One of the most destructive methods of attacking a computer system has been to send a “worm” to a computer program.
A worm is a self-propagating attack that exploits a vulnerability by taking control of the computer system and using that computer system to launch attacks (i.e., send the same worm) against other computer systems with the same vulnerability.
A worm is a message or sequence of messages designed to exploit a vulnerability of the receiving computer program. Upon receiving the message or messages, the computer program performs some action that allows the worm to take control of the computer system. Different vulnerabilities can be exploited in different ways, such as by sending network packets, streaming data, accessing a file system, modifying registry or configuration data, and so on, which are referred to as security events.
Developers of applications and administrators of computer systems go to great effort and expense to identify and remove vulnerabilities. Because of the complexity of applications, however, it is virtually impossible to identify and remove all vulnerabilities before applications are released. After an application is released, developers can become aware of vulnerabilities in various ways. A party with no malicious intent may identify a vulnerability in an application and may secretly notify the developer so the vulnerability can be removed before a hacker identifies and exploits it. If a hacker identifies a vulnerability first, the developer may not learn of the vulnerability until it is exploited—sometimes with disastrous consequences.
Regardless of how a developer finds out about a vulnerability, the developer typically develops and distributes to system administrators “patches” that remove the vulnerability. If the vulnerability has not yet been exploited (e.g., might not be known to hackers), then a developer can design, implement, test, and distribute a patch in a disciplined way. If the vulnerability has already been widely exposed, then the developer may rush to distribute a patch without the same care that is used under normal circumstances.
Intrusion detection systems have been developed that can be used to identify whether an attempt is being made to exploit a known vulnerability that has not yet been patched. These intrusion detection systems may define a “signature” for each way a vulnerability can be exploited. For example, if a vulnerability can be exploited by sending a certain type of message with a certain attribute, then the signature for that exploitation would specify that type and attribute. When a security event, such as the receipt of a message, occurs, the intrusion detection system checks its signatures to determine whether any match the security event. If so, then the intrusion detection system may take action to prevent the exploitation, such as dropping the message.
Signatures for newly discovered exploitations of vulnerabilities can be created in different ways. Developers of intrusion detection systems may create and distribute new signatures when they become aware of new exploitations.
Such signatures may be implemented as executable code that is specifically designed to detect and prevent a newly discovered exploitation. An administrator can then install the new signatures to prevent the exploitation. A developer may not, however, provide signatures for all known exploitations. For example, the vulnerability may be in a special-purpose application program that the developer does not support. To prevent exploitation of such vulnerabilities, intrusion detection systems may allow administrators to create their own signatures. These intrusion detection systems may provide a signature creation tool that lists various attributes of a security event and allows an administrator to set the values of those attributes to define the signature and actions to be taken to prevent the exploitation. When a security event matches the attribute values of the signature, then the intrusion detection systems takes the associated actions.
A difficulty with these intrusion detection systems is that since an administrator can only set the values for a limited set of security event attributes using the signature creation tool, the administrator may not be able to create signatures for certain exploitations. In such a case, a programmer would need to develop a signature with executable code for detecting and preventing the exploitation. Such development can be very expensive and time-consuming. Another difficulty is that the signature distributed by a developer of an intrusion detection system may result in a behavior that is not desired by the administrator. For example, the signature may be conservative in its assumption of which types of messages might exploit a vulnerability and discard all those messages. Such conservative assumption may result in many messages being discarded as a result of false positive detections. An administrator, however, may know that certain types may not be a problem in the environment of their computer system. When the desired signature cannot be created using the signature creation tool, the administrator may have no choice but to develop the executable code for the signature. It would be desirable to provide a tool that would allow an administrator to develop signatures that meet their needs without having to resort to developing custom executable code.